IRIX Installation Tools & Overlays 2004 February

home *** CD-ROM | disk | FTP | other *** search

/ IRIX Installation Tools & Overlays 2004 February / SGI IRIX Installation Tools & Overlays 2004 February - Disc 2.iso / relnotes / gl_dev / ch6.z / ch6

Wrap

Text File | 2004-01-09 | 32KB | 727 lines

- 1 - 6. _O_p_e_n_G_L OpenGL is supported on the following graphics adaptors: Indy - XL 8/24 bits Indigo - Starter, XS, XS24, XZ, Elan IndigoII - XL, XZ, Extreme, Solid Impact, Maximum Impact, High Impact Onyx - InfiniteReality, RealityEngine, RealityEngine2, VTX Onyx2 - InfiniteReality, Reality Octane - Octane MXI, Octane SSI and Octane SI Octane2 - Octane2 V6, Octane2 V8 These implementations pass Level 0 of the conformance tests (i.e., the "mustpass" test suite). In this release, the RealityEngine graphics adaptors do not pass level 0 of the conformance tests for OpenGL 1.1. (Please see the conformance reports for details.) 6.1 _D_o_c_u_m_e_n_t_a_t_i_o_n The following documentation is available for OpenGL: +o The _O_p_e_n_G_L _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e (Addison-Wesley, 1993) is a comprehensive guide to programming with OpenGL. +o The _O_p_e_n_G_L _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l (Addison-Wesley, 1992) contains an overview of OpenGL and man pages for all OpenGL, GLX and GLU functions. +o _O_p_e_n_G_L _o_n _S_i_l_i_c_o_n _G_r_a_p_h_i_c_s _S_y_s_t_e_m_s provides information that is essential for writing OpenGL applications in the X11 and IRIS IM environments, describes major SGI extensions to OpenGL, and gives advice for tuning OpenGL application performance. +o _T_h_e _O_p_e_n_G_L _P_o_r_t_i_n_g _G_u_i_d_e describes how to port programs that were written for IRIS GL. (Some of this information has been superseded by the material in _O_p_e_n_G_L _o_n _S_i_l_i_c_o_n _G_r_a_p_h_i_c_s _S_y_s_t_e_m_s.) +o The _I_R_I_S _P_r_o_g_r_a_m_m_i_n_g _N_o_t_e_s include documentation for X11, GL/GLX, Font Manager and mixed model programming in IRIS GL. The IRIS Development Option documentation includes online copies of _T_h_e _O_p_e_n_G_L _P_o_r_t_i_n_g _G_u_i_d_e, _O_p_e_n_G_L _o_n _S_i_l_i_c_o_n _G_r_a_p_h_i_c_s _S_y_s_t_e_m_s, the _I_R_I_S _P_r_o_g_r_a_m_m_i_n_g _N_o_t_e_s, the _O_p_e_n_G_L _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e, the _O_p_e_n_G_L _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l and reference pages (commonly known as ``man pages'') for all OpenGL, GLX - 2 - and GLU functions. It includes a hardcopy of the _O_p_e_n_G_L _P_r_o_g_r_a_m_m_i_n_g _G_u_i_d_e. You may also order a hardcopy of the porting guide (part number M4-OGLPort-5.1) and the _O_p_e_n_G_L _R_e_f_e_r_e_n_c_e _M_a_n_u_a_l (part number M4-OGLMAN-1.0). The reference pages for OpenGL commands have been updated with the latest information on machine-dependencies for each of the supported graphics adaptors. This includes performance tuning hints as well as known bugs and functionality subsetting warnings. If you're porting from IRIS GL to OpenGL, the best approach is to convert your program to a mixed-model program first (see the _I_R_I_S _P_r_o_g_r_a_m_m_i_n_g _N_o_t_e_s) and then consult _O_p_e_n_G_L _o_n _S_i_l_i_c_o_n _G_r_a_p_h_i_c_s _S_y_s_t_e_m_s followed by _T_h_e _O_p_e_n_G_L _P_o_r_t_i_n_g _G_u_i_d_e for more information. 6.2 _E_x_t_e_n_s_i_o_n_s The following OpenGL extensions are available in IRIX 6.5. For more information, please consult the _g_l_i_n_t_r_o reference page. +o _E_X_T__a_b_g_r extends the list of host-memory color formats. Specifically, it provides a reverse-order alternative to image format RGBA. The ABGR component order matches the cpack Iris GL format on big-endian machines. +o _S_G_I_X__a_s_y_n_c provides a way to allow certain OpenGL commands to complete out-of-order with respect to others. This extension does not by itself enable asynchrony; it is a framework establishing functions for bookkeeping and synchronization, into which specific further OpenGL extensions can be inserted. +o _S_G_I_X__a_s_y_n_c__p_i_x_e_l provides a new asynchronous mode for texture download, pixel download and pixel readback commands, in conjunction with the _S_G_I_X__a_s_y_n_c extension. It allows programs to transfer textures or images from the host to the graphics accelerator in parallel with the execution of other graphics commands. It also allows programs to issue non-blocking pixel readback commands that return immediately after they are issued, so that the program can issue other commands while the readback takes place. +o _S_G_I_X__b_l_e_n_d__a_l_p_h_a__m_i_n_m_a_x enhances _g_l_B_l_e_n_d_E_q_u_a_t_i_o_n by providing new blend equations which produce outcomes for all four color components based only on the comparison of the alpha component's source and destination values. Supported on Octane2 VPro systems. - 3 - +o _E_X_T__b_l_e_n_d__c_o_l_o_r allows a constant to be used as a factor in the blending equation. A typical use is to blend two RGB images. Without the constant blend factor, one image must have an alpha channel with each pixel set to the desired blend factor. +o _E_X_T__b_l_e_n_d__l_o_g_i_c__o_p defines an additional blending equation for _g_l_B_l_e_n_d_E_q_u_a_t_i_o_n_E_X_T. This equation is a simple logical combination of the source and destination colors. +o _E_X_T__b_l_e_n_d__m_i_n_m_a_x allows the blend equation to be changed using _g_l_B_l_e_n_d_E_q_u_a_t_i_o_n_E_X_T and introduces two new blend equations, one to produce the minimum color components of the source and destination colors and one to produce the maximum. +o _E_X_T__b_l_e_n_d__s_u_b_t_r_a_c_t defines two additional blending equations for use with _g_l_B_l_e_n_d_E_q_u_a_t_i_o_n_E_X_T. These new equations are similar to the default blending equation, but produce the difference of its terms, rather than the sum. Image differences are useful in many image processing applications. +o _S_G_I_X__c_l_i_p_m_a_p introduces new filtering and memory management techniques for handling extraordinarily large textures. Clipmaps provide many of the features of mipmaps, while using a small fraction of the texture memory required for mipmaps of equivalent size. They are especially useful for rendering terrain and roaming over large images. Clipmaps are supported on InfiniteReality systems. +o _S_G_I__c_o_l_o_r__m_a_t_r_i_x adds a 4x4 matrix stack and matrix multiplication to the pixel transfer path. The color matrix operates on RGBA pixel components. It can be used to reorder or duplicate color components, and to implement simple color-space conversions. +o _S_G_I__c_o_l_o_r__t_a_b_l_e defines a new RGBA-format color lookup table mechanism, and several new lookup tables in the OpenGL pixel path. The new lookup tables are treated as one-dimensional images with internal formats, like texture images and convolution filter images. This allows the tables to operate on a subset of the components of passing pixels. (For example, a table with internal format GL_ALPHA modifies only the A component of each passing pixel, leaving the R, G, and B components untouched.) A small subset of this extension is supported on RealityEngine, RealityEngine2, and VTX systems; because of this, the - 4 - extension is not listed in the extensions string returned by _g_l_G_e_t_S_t_r_i_n_g. The full extension is supported on all other systems. +o _E_X_T__c_o_n_v_o_l_u_t_i_o_n adds 1- or 2-dimensional convolution operations to the pixel transfer process. Pixel drawing, reading, and copying, as well as texture image definition, are candidates for convolution. The convolution kernels are themselves treated as 1- and 2-dimensional images, which can be loaded from application memory or from the framebuffer. A subset of this extension is supported on RealityEngine, RealityEngine2, and VTX systems; the full extension is supported on all other systems. +o _S_G_I_X__c_o_n_v_o_l_u_t_i_o_n__h_i_n_t provides a way to trade off convolution performance against arithmetic accuracy. Supported on Octane2 VPro systems. +o _E_X_T__c_o_p_y__t_e_x_t_u_r_e provides the ability to copy pixels directly from the framebuffer into texture memory. At present only a small subset of this extension has been implemented on RealityEngine, RealityEngine2, and VTX systems, so the extension name is not listed in the extensions string returned by _g_l_G_e_t_S_t_r_i_n_g. It is fully supported on all other systems. +o _S_G_I_S__d_e_t_a_i_l__t_e_x_t_u_r_e introduces texture magnification filters that blend between the level 0 image and a separately defined "detail" image. This detail blending can be enabled for all color channels, for the alpha channel only, or for the red, green, and blue channels only. It is available only for 2D textures. Supported on RealityEngine, RealityEngine2, and VTX systems, on InfiniteReality systems and on Octane2 VPro systems. +o _S_G_I_S__f_o_g__f_u_n_c_t_i_o_n Standard OpenGL defines three fog modes: GL_LINEAR, GL_EXP (exponential), and GL_EXP2 (exponential squared). Visual simulation systems can benefit from more sophisticated atmospheric effects. This extension provides the ability to define a custom fog blending function by specifying a set of control points that will be interpolated by the function. Supported on InfiniteReality and Octane2 VPro systems. +o _S_G_I_X__f_o_g__o_f_f_s_e_t In highly-fogged environments, emissive objects (like simulated automobile headlights or runway landing lights) can appear unrealistically dim. This extension brightens fogged objects by offsetting the Z value used in fog computations. Supported on InfiniteReality and Octane2 VPro systems. - 5 - +o _S_G_I_X__f_r_a_g_m_e_n_t__l_i_g_h_t_i_n_g provides a general lighting facility for lighting effects obtained by interpolation of normals over a primitive, rather than by interpolation of color. Supported on Octane2 VPro systems. +o _E_X_T__h_i_s_t_o_g_r_a_m defines pixel operations that count occurrences of specific color component values (histogram) and track the minimum and maximum color component values (minmax). An optional mode allows pixel data to be discarded after the histogram and/or minmax operations are completed. Otherwise the pixel data continue on to the next operation unaffected. +o _A_R_B__i_m_a_g_i_n_g defines a large set of image processing primitives, such as color tables, convolution, color matrices, histogramming, and additional blending behavior. The definition of this extension is provided as optional material in the OpenGL 1.2 specification. +o _S_G_I_X__i_n_t_e_r_l_a_c_e modifies the behavior of _g_l_D_r_a_w_P_i_x_e_l_s, _g_l_C_o_p_y_P_i_x_e_l_s, _g_l_T_e_x_I_m_a_g_e_2_D, _g_l_T_e_x_S_u_b_I_m_a_g_e_2_D_E_X_T, _g_l_C_o_p_y_T_e_x_I_m_a_g_e_2_D_E_X_T and _g_l_C_o_p_y_T_e_x_S_u_b_I_m_a_g_e_2_D_E_X_T, such that when GL_INTERLACE_SGIX is enabled the source image is considered to be a field of an "interlaced" frame. This is particularly useful for assembling consecutive interlaced video format fields to into a complete frame in either the framebuffer or in texture memory. Supported on RealityEngine, RealityEngine2, and VTX systems and on InfiniteReality systems. +o _S_G_I_X__l_i_s_t__p_r_i_o_r_i_t_y defines a mechanism to specify priorities for display lists. Some machines have special high-performance display list memories; this extension allows the user to tell the GL which display lists should be stored in those memories. Supported on InfiniteReality and Octane2 VPro systems. +o _S_G_I_S__m_u_l_t_i_s_a_m_p_l_e provides a mechanism to antialias all primitives. The technique is to sample all primitives multiple times at different locations within each pixel (rather than just the pixel center). The color sample values are resolved to a single, displayable color each time a pixel is updated, so the antialiasing appears to be automatic at the application level. Supported on RealityEngine, RealityEngine2, and VTX systems and on InfiniteReality systems. +o _E_X_T__p_a_c_k_e_d__p_i_x_e_l_s provides support for packed pixels in host memory. A packed pixel is represented entirely by one unsigned byte, one unsigned short, or one unsigned - 6 - integer. The fields with the packed pixel are not proper machine types, but the pixel as a whole is. Thus the pixel storage modes, and their unpacking counterparts, all work correctly with packed pixels. This extension is not supported on RealityEngine, RealityEngine2, and VTX systems. +o _E_X_T__p_o_l_y_g_o_n__o_f_f_s_e_t allows depth values of fragments to be displaced so that lines (or points) and polygons that lie in the same plane can be rendered without interaction -- the lines are rendered either completely in front of or behind the polygons (depending on the sign of the offset factor). It also allows multiple coplanar polygons to be rendered without interaction, if different offset factors are used for each polygon. +o _S_G_I_X__r_e_f_e_r_e_n_c_e__p_l_a_n_e allows a group of coplanar primitives to be rendered without depth-buffering artifacts. This is accomplished by generating the depth values for all the primitives from a single ``reference plane'' rather than from the primitives themselves. This ensures that all the primitives in the group have exactly the same depth value at any given sample point, no matter what imprecision may exist in the original specifications of the primitives or in the GL's coordinate transformation process. _S_G_I_X__r_e_f_e_r_e_n_c_e__p_l_a_n_e is useful for generating hidden- line drawings, for applying decals to polygons, and for multipass rendering techniques. Supported on InfiniteReality systems. +o _S_G_I_X__r_e_s_a_m_p_l_e enhances the unpacking resampling capabilities of the _S_G_I_X__s_u_b_s_a_m_p_l_e extension. Supported on Octane2 VPro systems. +o _S_G_I_X__s_h_a_d_o_w provides support for rendering shadows using shadow maps. First the application renders the scene from the point of view of the light source, and copies the resulting depth buffer to a texture with internal format GL_DEPTH_COMPONENT. Next the application renders the scene from the normal viewpoint. Then the application enables the texture parameter GL_TEXTURE_COMPARE_SGIX, sets the texture comparison operator and texture matrix appropriately, and re-renders the scene with 2D texturing enabled. During this final rendering pass, the depth value generated by iterating the _r texture coordinate is compared with the shadow map stored in texture memory, and the results of the comparison indicate whether the pixel being textured is in shadow. The filtered result of the shadow comparisons can be blended with the pixel - 7 - to darken it. Supported on InfiniteReality systems. +o _S_G_I_X__s_h_a_d_o_w__a_m_b_i_e_n_t controls the filtered texture value generated in shadowed regions (see _S_G_I_X__s_h_a_d_o_w). In effect, this changes the ambient lighting in shadows. Supported on InfiniteReality systems. +o _S_G_I_S__s_h_a_r_p_e_n__t_e_x_t_u_r_e introduces texture magnification filters that sharpen the resulting image by extrapolating from the level 1 image to the level 0 image. Sharpening can be enabled for all color channels, for the alpha channel only, or for the red, green, and blue channels only. Supported on RealityEngine, RealityEngine2, and VTX systems and on InfiniteReality systems. +o _S_G_I_X__s_u_b_s_a_m_p_l_e defines new pixel storage modes used in the conversion of image data to and from component subsampled formats on the client side. Supported on Octane2 VPro systems. +o _E_X_T__s_u_b_t_e_x_t_u_r_e allows a contiguous portion of an already-existing texture image to be redefined without affecting the remaining portion of the image or any of the other state that describes the texture. There are three new calls: _g_l_T_e_x_S_u_b_I_m_a_g_e_1_D_E_X_T, _g_l_T_e_x_S_u_b_I_m_a_g_e_2_D_E_X_T, and _g_l_T_e_x_S_u_b_I_m_a_g_e_3_D_E_X_T. A subset of this extension is available on RealityEngine, RealityEngine2, and VTX systems, and the full extension is available on all other systems. +o _E_X_T__t_e_x_t_u_r_e provides support for a variety of resolutions of color components in texture images. That is, instead of treating a retained image as having 1, 2, 3, or 4 components, it is treated as though it had a specific format, such as GL_LUMINANCE_ALPHA, or just GL_ALPHA. This extension also defines a robust method for applications to determine what combinations of texture dimensions and resolutions are supported by an implementation and it introduces a new texture environment: GL_REPLACE_EXT. +o _E_X_T__t_e_x_t_u_r_e_3_D supports 3-dimensional texture mapping. It also defines the in-memory formats for 3D images, and adds pixel storage modes to support them. +o _S_G_I_X__t_e_x_t_u_r_e__a_d_d__e_n_v defines a new texture environment function which scales the texture value by the constant texture color and then adds a bias color. Supported only on InfiniteReality systems. - 8 - +o _S_G_I_S__t_e_x_t_u_r_e__b_o_r_d_e_r__c_l_a_m_p provides a variation in the texture clamping arithmetic which results in sampling the border color rather than the average of the edge and border colors. Supported on Octane2 VPro systems. +o _S_G_I_S__t_e_x_t_u_r_e__c_o_l_o_r__m_a_s_k specifies which color components of the texture elements in an image are affected by the commands that define texture images. Supported on Octane2 VPro systems. +o _S_G_I__t_e_x_t_u_r_e__c_o_l_o_r__t_a_b_l_e adds a color lookup table to the texture mapping process. +o _S_G_I_X__t_e_x_t_u_r_e__c_o_o_r_d_i_n_a_t_e__c_l_a_m_p provides a way to set the maximum texture coordinate clamping value to something other than 1.0. Supported on Octane2 VPro systems. +o _S_G_I_S__t_e_x_t_u_r_e__e_d_g_e__c_l_a_m_p The GL normally clamps texture coordinates to the range [0,1]. This can cause the texture sampling filter to straddle the edge of the texture image, taking half its sample values from within the texture image, and the other half from the texture border. Sometimes this is undesirable. _S_G_I_S__t_e_x_t_u_r_e__e_d_g_e__c_l_a_m_p defines a new texture clamping method that ensures all sample values fall within the texture image. Supported on InfiniteReality and Octane2 VPro systems. +o _E_X_T__t_e_x_t_u_r_e__e_n_v__a_d_d defines a new texture environment function which simply adds the texture color to the fragment color. +o _S_G_I_S__t_e_x_t_u_r_e__f_i_l_t_e_r_4 allows 1D and 2D textures to be filtered using an application-defined symmetric and separable filter with four samples per dimension. In the most common 2D case, the filter is bicubic. This filtering can yield better-quality images than mipmapping, and is often used in image processing applications. Supported on InfiniteReality systems. +o _S_G_I_S__t_e_x_t_u_r_e__l_o_d provides mechanisms that reduce the number of mipmap levels required for mipmapped texturing. This allows a large texture to be loaded and used initially at low resolution, and to increase the resolution gradually as time passes or as more mipmap levels become available. Supported on InfiniteReality and Octane2 VPro systems. +o _S_G_I_X__t_e_x_t_u_r_e__l_o_d__b_i_a_s provides mechanisms that apply a bias to the n, m and l parameters in the LOD calculation, to compensate for over- or under-sampled - 9 - texture images. Supported on InfiniteReality and Octane2 VPro systems. +o _E_X_T__t_e_x_t_u_r_e__o_b_j_e_c_t supports named texture objects whose contents and parameters may be changed after they are defined. (Contrast this with textures in display lists, which cannot be modified after the display lists are created.) For machines with special texture memories, _E_X_T__t_e_x_t_u_r_e__o_b_j_e_c_t also provides simple texture memory management. +o _S_G_I_X__t_e_x_t_u_r_e__s_c_a_l_e__b_i_a_s adds scale, bias, and clamp operations to the texture pipeline. These operations are applied to the filtered result of a texture lookup, before that result is used in the texture environment equations and before the texture color lookup table of _S_G_I__t_e_x_t_u_r_e__c_o_l_o_r__t_a_b_l_e. +o _E_X_T__v_e_r_t_e_x__a_r_r_a_y adds the ability to specify multiple geometric primitives with very few subroutine calls. Instead of calling an OpenGL procedure to pass each individual vertex, normal, or color, separate arrays of vertexes, normals, and colors are prespecified, and are used to define a sequence of primitives (all of the same type) when a single call is made to _g_l_D_r_a_w_A_r_r_a_y_s_E_X_T. A stride mechanism is provided so that an application can choose to keep all vertex data staggered in a single array, or sparsely in separate arrays, but single-array storage generally will provide better performance. This extension also supports the rendering of individual array elements, each specified as an index into the enabled arrays. +o _S_G_I_X__v_e_r_t_e_x__p_r_e_c_l_i_p supplies a way to control the precision of interpolation of parameters across the extent of primitives with large screen space dimensions. This control allows trading off precision for higher rasterization performance. Supported on Octane2 VPro systems. The following GLX extensions are available in 6.5. For detailed information, please consult the _g_l_x_i_n_t_r_o reference page. +o _S_G_I_X__f_b_c_o_n_f_i_g introduces a new way to describe the capabilities of a GLX drawable (i.e., to describe the depth of color buffer components and the type and size of ancillary buffers), removes the "similarity" requirement when making a context current to a drawable, and supports RGBA rendering to one- and two- component Windows and GLX Pixmaps. - 10 - +o _E_X_T__i_m_p_o_r_t__c_o_n_t_e_x_t allows multiple X clients to share an indirect rendering context. Also, two convenience routines are added: one to get the display for the current context and one to retrieve the attributes that a context was created with. +o _S_G_I__m_a_k_e__c_u_r_r_e_n_t__r_e_a_d allows OpenGL pixel operations to read pixel data from the buffers of one drawable and draw into the buffers of another. For example, pixels can be copied from one window into another, or from a GLXPbuffer into a window. +o _S_G_I_S__m_u_l_t_i_s_a_m_p_l_e provides a mechanism to antialias all primitives. In order to support multisampling both GLX and OpenGL had to be extended. The GLX portion of the extension includes new visual attributes which can be specified when calling _g_l_X_C_h_o_o_s_e_V_i_s_u_a_l and _g_l_X_G_e_t_C_o_n_f_i_g. This extension is supported on RealityEngine, RealityEngine2, and VTX systems, and on InfiniteReality systems. +o _S_G_I_X__p_b_u_f_f_e_r defines GLX pixel buffers, which are additional non-visible rendering buffers for an OpenGL renderer. GLX pixel buffers are typically allocated in non-visible frame buffer memory. They are intended to be "static" resources, in that a program will typically allocate them only once, rather than as a part of its rendering loop. Also the frame buffer resources that are associated with a GLX pixel buffer are static, and are deallocated only when the GLXPbuffer is destroyed, or, in the case of a _u_n_p_r_e_s_e_r_v_e_d GLX pixel buffer, as a result of X server activity that changes its frame buffer requirements. +o _S_G_I__s_w_a_p__c_o_n_t_r_o_l provides new parameters that modify the semantics of _g_l_S_w_a_p_B_u_f_f_e_r_s. With this extension an application can specify a minimum periodicity for color buffer swaps, measured in display retrace periods. +o _S_G_I_X__v_i_d_e_o__r_e_s_i_z_e allows the frame buffer to be resized to the output resolution of the video channel when _S_w_a_p_B_u_f_f_e_r_s is called for the window that is bound to the video channel. This extension is supported only on InfiniteReality systems. +o _S_G_I_X__v_i_d_e_o__s_o_u_r_c_e allows pixel data to be sourced from a video input stream. It defines a new type of drawable, GLXVideoSourceSGIX, that represents the drain node of a Video Library (VL) path. A GLXVideoSourceSGIX may be passed as a parameter to _g_l_X_M_a_k_e_C_u_r_r_e_n_t_R_e_a_d_S_G_I to indicate that pixel data - 11 - should be read from the specified video source instead of from the framebuffer. +o _S_G_I__v_i_d_e_o__s_y_n_c provides a means for synchronization with the video frame rate of a monitor - or, in the case of an interlaced monitor, with the field rate of the monitor. +o _E_X_T__v_i_s_u_a_l__i_n_f_o allows the user to request a particular X visual type to be associated with a GLX visual, and allows the user to query the X visual type underlying a GLX visual. In addition, this extension provides a means to request a visual with a transparent pixel and to query whether a visual supports a transparent pixel value and the value of the transparent pixel. +o _E_X_T__v_i_s_u_a_l__r_a_t_i_n_g allows servers to identify a particular GLX visual as undesirable. This allows servers to export visuals with improved features or image quality, but lower performance or greater system burden, without having to have these visuals selected preferentially.